Not all games require fighting. Races and exploration can be lots of fun, and don't require players to be bashing each other. However, the excitement of most Xconq games derives from the chances of going up against an opponent directly.
Combat includes five distinct action types that a player may choose from, not counting detonation, and you specify the characteristics of each. "Attack" is hand-to-hand with another unit, "capture" attempts to change the side without damaging, "fire-at" hits a unit without getting entangled, while "fire-into" hits everything in a targeted cell. Finally, "overrun" is an attempt to occupy a cell, doing whatever combination of attack, capture, and movement is necessary.
To specify what kinds of battles are possible, you begin by setting
the hit-chance of some unit vs another unit to any value
greater than zero. A hit probability of zero completely disallows
attack. A hit probability of 100 is a guaranteed hit.
In practice, you will probably need to specify most hit probabilities
individually.
[describe mods to hit prob?]
Next you need to set the damage done by a hit. The default value is 1 hp, which is a good starting place but not always particularly realistic.
[describe variation parms]
As usual, you can define the action point cost of combat,
via acp-to-attack and acp-to-defend.
The use of separate tables for attacker and defender allows for
some extra flexibility. This is important, because sometimes you
want to allow combat to keep a defender busy and soak up its acp,
while at other times attempts to engage in combat should be shrugged off.
Consider battleships vs infantry; although combat between the two
rarely causes much damage, an attack by a battleship will cause the
infantry to keep their heads down, and preventing them from doing much else,
while the return rifle fire is unlikely to disturb the battleship much!
Describing simple hit probabilities and damage is oftentimes sufficient for a game. It's simple; players can learn the numbers by heart. It's more efficient, because there's no need to manage lots of ongoing battles. However, there are endless numbers of situations where this basic model is unsatisfactory, so let's move on to the available enhancements.
The basic parameter for the firing actions is range of the unit,
which is the greatest reach possible.
You can also set a range-min, which is useful for ballistic
missiles, certain kinds of artillery,
and magic spells that can't be used for close-in fighting;
you can't fire at a unit that is less than range-min cells away.
Also, you can define how transports and occupants affect each other in
combat. The effects can be both positive and negative, and extend both
from occupants to their transport and from the transport to its occupants.
The table transport-protection defines the percentage of hit damage
(by any unit type) that gets passed through to each occupant.
If 0, then the transport is perfect protection. If 100, then each occupant
gets the same hit as the transport did.
[Ideally, protection is a prorating on a table value from occupant vs attacking
unit.]
Note that an occupant cannot be attacked directly from outside its transport.
If you want to make combat dependent on having a supply of ammo, use the
tables hits-with and hit-by.
The material type need not be explicitly designated as ammo,
but both the hitting and hit units must agree that the same type
is effectual (we assume that the attacking unit is smart enough not to
use material types that have no effect on the target unit).
[need a combat-supply usage in addition]
[Multi-round battles are not yet available.]
Capture is both a distinct action type and a possible consequence of normal combat. As an action, it is useful for both "bloodless" captures and the collecting of objects from a dungeon floor.
To allow explicit attempts to capture, set acp-to-capture
to 1 or more.
Whether the capture attempt is explicit or a consequence of combat,
its basic probability of success is derived from the table
capture-chance.
If the unit being captured is independent, there is a separate
table independent-capture-chance; if its value is the default
of -1, then the value of capture-chance will be used instead.
For capture attempts that are going to succeed, you can allow
the victim a chance to wreck itself first, by setting scuttle-chance.
The main effect of capture is simply to change the side of the
unit that was captured. If the unit cannot be on the capturing
side, then it will vanish instead. In any case, the occupants
will also be captured or vanish,
although you give them a chance to escape first via
occupant-escape-chance. They will also attempt to
scuttle themselves if possible.
You can also require a sacrifice from the capturing unit,
via the table hp-to-garrison. This is the number
of hp that will be taken from the capturing unit.
You can set it to the unit's hp-max to make it
disappear entirely. Although this table is inspired
by realism, it can also serve a pragmatic purpose,
namely to prevent a single unit from capturing an
entire country without being affected at all!
You should set this table according to the "feel"
you want for the game, since it can have a major
effect on speed and pacing of the play.
As with normal combat, the experience of both the
capturing and captured unit may change.
For the capturing unit, this is a gain defined by
cxp-per-capture, while the effect on the
capturing unit is set by cxp-on-capture-effect,
which is a multiplier (defaulting to 100) that may
increase or decrease experience. In practice,
a decrease is more realistic, representing perhaps
the replacement of ship or airplane crews, although
a increase might be more appropriate for mercenaries
whose response to capture is simply to go to work
for the new bosses!
Detonation is both a type of action detonate
and an automatic behavior.
Detonation can damage both the detonating unit (though it need not)
and any units around its point of detonation, which may or may not
be its location. You set it up by defining acp-to-detonate
to one or more, set hp-per-detonation to express
the amount of damage done to the detonating unit,
then fill in the detonation damage tables
detonation-damage-at and detonation-damage-adjacent
to say how badly each type of nearby unit will be hit.
You can define the exact radius of effect via detonation-range.
The effects on occupants of nearby units will be adjusted
according to the same protection/ablation tables as for combat.
You can also set detonation to trigger on various kinds of events,
such as damage to the detonating unit (detonate-on-hit,
death of the detonating units (detonate-on-death),
impending capture (detonate-on-capture),
and proximity of certain types of units (detonate-on-approach).
You can also set a chance that a unit will detonate spontaneously,
via detonation-accident-chance.
In order to model the catastrophic effects of the worst explosives,
you can set terrain-damage to indicate how terrain types will
change.
A minefield could be implemented by defining a detonating unit that loses some small percentage of its hp every time a unit hits it, while hitting the other unit automatically.
A simple trap would auto-detonate only once, then change to a "sprung trap" type. Then the right kind of unit could come along and do a change type action to reset it.